Welcome to EtherHelp by The AG Group! The AG Group specializes in easy-to-use software tools for troubleshooting, optimizing, maintaining and expanding multivendor computer networks. While designed to take advantage of the intuitive, graphical interface of the Macintosh, our products can be used in virtually any heterogeneous networking environment.
This Reference Guide is intended to provide a more complete reference for EtherHelp users. Please review the Basic Guide for a capsulized overview of use of the application.
Installing EtherHelp
When copying the EtherHelp program to a hard disk, you must also copy the Hardware Interface file. The modules that operate the Ethernet hardware reside in the folder called “Hardware Interfaces.”
TIP: One recommended procedure is to keep EtherHelp and its related files on a floppy disk. This allows you to visit various locations of the network, insert the floppy disk, run EtherHelp and monitor the network from that location.
Hardware Requirements
EtherHelp runs on the following Macintosh computers:
All members of the Macintosh II Family, SE/30, Powerbooks, LCs, Portable, Quadras & Centris
You will need to be sure your Ethernet hardware is installed before you can capture packets with EtherHelp. The Macintosh must be equipped with at least one of the following supported Ethernet interface cards:
Dayna Communications DaynaPort SE/30, II, SI, LC, LCII, SCSI/Link
Dove FastNet IIIn
Farallon PhoneNet® IIN, SE30, EtherCard Series
Kinetics/Excelan EtherPort IIn
National Semiconductor EtherNODE-16NB/32NB
Network Resources Mac 1000 & 2000 Series
Novell EtherPort IIN, SE/30
Nuvotech NuvoLink II
Racal Interlan NIA310 Ethernet Card
Shiva EtherPort II, SE/30
Sonic Systems EtherTnt, EtherTwp
Technology Works Mac II Ethernet, EtherSC
3Com EtherLink NB
Tri-Data Systems LanWay E-10
Software
EtherHelp requires Macintosh System 6.0.5 or later and is fully-compatible with System 7.X. It also requires AppleTalk version 54 or greater. EtherHelp uses its own software to interface with the Ethernet card and is not dependent upon vendor-supplied software drivers.
Memory
EtherHelp is normally configured to use 1MB of memory. However, it may be configured to run with more if you wish a larger capture buffer. The amount of memory you assign depends upon the number of packets you wish to capture and the RAM available. To change the memory size allocated, select the EtherHelp icon from the Finder and choose the "Get Info…" command in the File menu, then change the value for Application Memory Size (K).
TIP: To use memory more efficiently, it may not be necessary to capture every packet to understand what is happening on your network. That is why EtherHelp provides capture filtering.
Compatibility
EtherHelp is compatible with almost all applications except those which require the use of a network connection (including INITs). If AppleTalk network services run on the same Ethernet interface through which you intend to monitor your network, you should quit or disable those programs before running EtherHelp. Very often, AppleTalk network software will register itself as an AppleTalk client. EtherHelp must “unregister” all services to monitor the network, which may leave these other network programs in an undesirable or undefined state. If the network software is an application, exit the program. If it is a startup document, take it out of the System Folder and restart the Mac. Some programs can be disabled through the Chooser or through a related icon in the Control Panel or on the desktop. Another solution might be to configure these programs to use LocalTalk (Built-in) or TokenTalk, if possible, instead of EtherTalk.
If your Macintosh has 2 Ethernet cards installed, one card can be used for your normal network transactions and the other for EtherHelp. When 2 cards are installed, it is not necessary to quit or disable other networking services. It is only necessary to specify which card is to be used for your normal network services and which card is to be used for EtherHelp. Use "Select Ethernet" under the File menu to specify which Ethernet card EtherHelp should use.
WARNING: If you are NOT running EtherHelp with two Ethernet cards, it is imperative to disable all network services on the Mac running EtherHelp, even if you will not be capturing the packet types used by those programs. EtherHelp puts the Ethernet card into “Promiscuous Mode,” and if these programs are running, they may get packets that were meant for other machines on the network. These programs may then try to process some of those packets and may even respond to them, confusing your attempt to analyze events and creating problems on the network.
Network Services
When you begin capturing or sending packets with EtherHelp, the program will ask if it is okay to disconnect from these services by presenting a warning message. If you choose "Disconnect Services", EtherHelp will prevent the use of AppleTalk or any other network services, which means that the network software on your Macintosh will no longer function properly. You may prevent the disconnection from taking place by clicking on the "Cancel" button. After choosing Cancel, you can quit EtherHelp and disconnect these network services through their own normal termination sequence. If you don’t want EtherHelp to give you this warning when you first begin a capture session, use the Chooser to make AppleTalk inactive by clicking on the "Inactive" button. Or, choose to run AppleTalk on LocalTalk by selecting "Built-in" (or by using a Token Ring card with TokenTalk installed), and selecting the appropriate icon in the Network Control Panel instead of EtherTalk. When you have finished running EtherHelp, if you previously had selected "Built-in" in the Network Control Panel, you may again select "EtherTalk" or, if you had made AppleTalk inactive in the Chooser, you should enable it again by clicking on the "Active" button. This will allow AppleTalk to use the Ethernet card in your Macintosh again.
Types of Filtering Available
If your network is very busy, you will quickly find that the number of packets EtherHelp captures in a short time can be quite large. Finding the packets in which you are interested can be difficult and time-consuming. For this reason, EtherHelp provides many pre-configured filters to eliminate the inconsequential or uninteresting packets from your packet capture. See the section below on Filtering.
Ethernet Addresses
When a packet is formed, there are 14 bytes of packet header information, followed by the data portion of the packet. The first 12 bytes of the packet header are the destination and source address, respectively (six bytes each). In this document, we refer to these two addresses as physical addresses. Depending on the type of protocol in the packet (e. g. DECnet, AppleTalk, IP), there may be more bytes of information later in the packet which also specify source and destination address information, either as extensions to the physical addresses or as alternatives to them. These higher level (network layer) addresses are called logical addresses. The logical addresses are used by networking software to allow packets to be independent of the physical connection of the network. For example, if you were sending a packet to a different network, the higher-level, logical destination address might be for the computer on that network to which you are sending the packet, while the lower-level, physical Ethernet address might be the physical address of an inter-network device that bridges the two networks and is responsible for forwarding the packet to the ultimate destination. Fundamentally, every node on an Ethernet must have its own, unique, physical address. As a general practice, a manufacturer of Ethernet node equipment will obtain its own block of physical address numbers from the IEEE which are then assigned uniquely to each node that the manufacturer builds. In this way, Ethernet physical addresses are generally distinct from each other, although some networks and protocols will override this built-in mechanism with one of their own. The block of addresses is usually designated by 3 bytes which form the most significant bytes of the 6-byte physical Ethernet address.
Broadcast and Multicast
Some physical addresses have a special meaning known as Broadcast and Multicast. A destination physical address with all the address bits turned on (FF:FF:FF:FF:FF:FF) is the broadcast address and means that the packet should be accepted by all nodes on the network which permit the receiving of broadcast packets. While conceptually very powerful, broadcast packets can be very expensive in terms of network resources as every single node on the network must spend the time and memory to receive and process the packet, even if the broadcast has no meaning or value for that node. Multicast is similar in concept to broadcast with some important improvements. There are many different Multicast addresses each of which is used for a different “broadcast” function. In this way, the broadcast traffic can be separated into different types based upon some criteria, such as protocol. Then, Ethernet nodes can be set up to only receive the types of broadcast (i. e. the multicast addresses) which have meaning for them.
The importance of Broadcast vs. Multicast is amplified in environments where the network is multiple segments connected by routers and gateways and where the number of nodes on the network is large. A broadcast packet would need to be retransmitted by every router and gateway on every segment to every node. For this reason, most routers and gateways have options to prevent the retransmission and propagation of broadcast packets. On the other hand, a multicast packet can be selectively retransmitted onto the segments where the packet has some validity, which may be a much smaller number of nodes and much less overall traffic.
Error Packets
EtherHelp recognizes and can capture four different types of error packets:
• Frame Error - Each byte is transmitted onto Ethernet a bit at a time, and the Ethernet receiver hardware collects the bits back into 8-bit bytes. A Frame Error is detected at the end of a packet when the number of bits received is not a multiple of eight, i. e., does not collect evenly into a number of 8-bit bytes.
• CRC Error- A CRC (cyclic-redundancy check) Error occurs when the Frame Check Sequence (FCS) fails. As every byte is transmitted and received on the network, the byte is also used to determine a 32-bit checksum value from a polynomial equation. At the end of the packet, four additional bytes are transmitted which force the checksum to a known constant. On the receiving end, for every byte received, if the checksum does not match the known constant, a CRC error is flagged, but it really doesn’t matter if it matches until after all bytes including the CRC bytes are received. Nearly all Ethernet devices use hardware which automatically computes, generates and checks the correct CRC information without software computation. EtherHelp checks the status of the CRC flag in this hardware only after the packet is completely received. A CRC error often occurs because some other error has occurred.
• Runt Packet- By definition, Ethernet packets must be between 64 and 1,518 bytes long, including the 12 bytes of destination and source address, 2 bytes of length or protocol type field and the 4 bytes of FCS. A Runt packet is an Ethernet packet that is at least 8 bytes but fewer than 64 bytes long.
• Oversize Packet- An Oversize packet is an Ethernet packet longer than 1,518 bytes.
Filtering
EtherHelp provides "filters" to eliminate the inconsequential or uninteresting packets from your review when you have a lot of network traffic. Use EtherHelp filters in the following ways:
• Capture filters tell EtherHelp which packets to capture. Enabled capture filters are applied to packets before they are placed in the capture buffer. This maximizes application memory by saving only specified packets, and allows you to focus on packets that are useful in analyzing or monitoring the network.
• Start triggers specify an event that triggers EtherHelp to start capturing packets. A start trigger is a specification that tells EtherHelp to remain idle, reviewing but not capturing packets, until a specified event occurs. When the trigger event occurs, you can specify that EtherHelp begins capture (after applying all enabled filters), notifies you by playing an audible alarm or sending a message to your electronic paging unit, or performs a combination of these actions. Triggers are most useful when you suspect a network problem but have been unable to verify or reproduce it. By setting up a start trigger, you can wait until the event occurs to begin your capture activity. Or, if you know that the problem occurs at a particular time, you can set a time event to begin capturing packets during that time.
To enable capture filtering, follow these steps:
1. Choose "Filters..." in the Capture menu to open the Filters window.
2. At the top of the window, click the appropriate radio button to instruct EtherHelp to capture or not capture packets according to the filters.
3. Click the check box preceding the filter(s) you want to enable. When a filter is enabled, a check mark appears in the check box. To disable the filter, click once on the check mark.
NOTE: If multiple capture filters are enabled in the Filters window, the multiple filters are OR'd together, so any packet that meets all of the testing criteria of any one of the selected filters will be accepted.
Creating and Editing Filters
There are two ways to open the Filter Settings window, where filters are defined. You can double-click a filter name in the Filters window which will open the Filters Settings window, showing the settings for the selected filter or use the "Filters" menu, which EtherHelp adds to its menu bar when "Filtering..." is selected in the Capture menu. Instead of clicking in the box that precedes a filter's name, you can use the Filters menu to enable or disable a selected filter by choosing Add... in the Filters menu to open the Filters Settings window with no existing settings or name. When you open the Filter Settings window by choosing Add..., you will see an "Add More..." button between the OK and Cancel buttons. When you click "Add More...", the current filter is added to the list and all information is retained in the Filter Settings window. This is useful if you want to create additional filters with similar specifications.
Each filter can have up to 4 attributes, each of which can be enabled or disabled in a filter:
• Address attributes test each packet's source or destination address (or both). Address filtering is used to capture or ignore packets to or from particular devices.
• Protocol attributes test the protocol type in a packet. Protocol filtering is used to capture or ignore packets of a specified protocol type, such as AppleTalk, DECnet, Ethernet, etc.
• Offset attributes test specific bytes or bits in each packet for a user-defined value. Offset filtering is used to specify exactly which packets you want to capture or ignore.
• Error attributes test for particular error conditions in packets.
When To Use Address Filters
Address filtering is very useful for focusing on packets between specific network devices. Using EtherHelp's ability to capture packets based upon embedded logical addresses, you may even monitor packets on your network sent to and received from machines on remote networks. If your network contains a link to other networks, you can monitor the network activity through the link by using an address filter to capture only packets containing the link device's address.
Using "Wild Cards" To Specify a Range of Addresses
You can use the asterisk (*) character as a "wild card" in specifying physical or logical addresses. The (*) character matches any number in the field in which it appears. For example, to refer to all stations using Western Digital Ethernet cards, you can specify the Western Digital vendor ID followed by asterisks in the card-ID fields: "00:00:c0:*:*:*". To match any host on the class "C" IP network "200.10.10", you can specify the IP network number followed by an (*) in the host field: 200.10.10.*
Capturing All Packets From One Device
This example creates a filter that can be used to capture or ignore all packets being transmitted from a particular AppleTalk node:
1. Select "Filtering..." from the Capture menu.
2. Select "Add..." from the Filters menu and the Filters Settings window will open.
3. Type a name (up to 23 characters) in the Filter: edit field at the top of the window.
4. Click the Address Filter check box.
5. Choose an address type from the Type pop-up menu. In this example, choose AppleTalk.
6. Click the Address-1 edit field, and enter a logical AppleTalk node address in that field.
NOTE: The node address you specify must be consistent with the address type you selected in the Type menu. If you had selected Ethernet instead of AppleTalk, you would need to enter the device's physical address.
7. Click next to "Any Address" in the Address-2 box.
8. Click next to "From Address-1 to Address-2". When you click in a "From Address..." check box, an arrow appears in the middle of the address filters area, to indicate the direction of the filter. Clicking on this arrow cycles through the possible directions (source, destination, or both) and is a shortcut for clicking the From Address... boxes.
To capture packets that are destined for a specific device, click next to "From Address-2 to Address-1" instead. You should see a left-pointing arrow appear in the middle of the address filter area. To capture packets sent to and received from a device to monitor traffic in and out of a specific address, click next to "From Address-2 to Address-1" and next to "From Address-1 to Address-2". A bidirectional arrow appears.
To monitor traffic in either direction (or in both directions) between two devices, turn off the "Any Address" button in the Address-2 box and enter the second specific address in the Address-2 field. Then click both check boxes: "From Address-1 to Address-2" and "From Address-2 to Address-1".
Protocol Filters
Protocol filtering allows you to capture only packets of a certain protocol type.
Using "Wild Cards" to Specify Protocols
You can use the (*) character as a "wild card" in specifying protocol types. The (*) matches any number in the field in which it appears. For example, the DECnet protocols use the following 2-byte Ethernet protocol specifications:
60-02 DEC_MOP
60-03 DEC_Transport
60-04 DEC_LAT
60-06 DEC_UPT
60-07 DEC_Control
You can represent the entire DECnet suite by using the wild card "60-*".
Creating Protocol Filters
There are two ways to specify a protocol type in a filter: by protocol name or by the hex representation of the LSAP or SNAP values for the protocol. The following example creates a filter that can be used to capture or ignore all XNS packets:
1. Select "Filtering..." from the Capture menu.
2. Select "Add..." from the Filters menu.
3. Type a name in the Filter: edit field.
4. Click the Protocol Filter check box.
5. Choose the appropriate specification from the protocol Type pop-up menu. XNS is identified by a 1-byte LSAP value, so choose the 802.2 LSAP value type.
6. Type the 1-byte hex number for XNS in the Protocol: field.
7. Click OK and close the window, or click Add More... if you wish to define additional filters.
Offset Filters
Offset filtering allows you to pinpoint packets by capturing a packet only if it meets very specific criteria based upon the value of certain bits or bytes. An offset is the byte number where certain information or data occurs in a packet.
For most uses of EtherHelp, address and protocol filtering are sufficient to specify the network activity you wish to view. However, you may occasionally wish to filter packets based on more rigorous criteria. For example, you may want to capture only packets that have a socket number of 6, or you may want to collect only ICMP packets with an Unreachable Destination error number.
Each offset filter can test up to 16 bytes in a packet for a specified value at each location. If all of the "active" tests in a filter pass (and the filter is enabled), the packet is captured.
NOTE: Use offset filters with an address filter to fine-tune the packets you wish to view. For example, you can use an addess filter to specify a particular AppleTalk router, and then set an offset filter that specifies the standard offset for NBP-Long packets with a further offset limiting packet capture to only those packets being routed into a particular network. With offset filters, you can specify completely the exact packets you wish to view.
Offset Filters At Work
This section describes the "test" values you can enter in the Offset Filter window to pinpoint the byte and which bits within that byte you want to use in the filter. To open the Offset Filter window, follow these steps:
1. Select Filtering... form the Capture menu.
2. Select Add... from the Filters menu.
3. Click the Offset Filter button to open the Offset Filter window. In this window, there are 16 rows, each of which can be used to specify a test for one location in a packet. Each row has four fields and an enable switch. The four fields are as follows:
• Name - The text in this field (up to 23 characters) is optional and does not affect the filtering of packets. It is used to help you remeber the meaning of the specified values.
• Offset - The number in this field indicates the location of a byte in the packet. If you enter 0, the first byte of a packet will be examined, 1 causes EtherHelp to examine the second byte and so forth. You can enter the number in hex ($0 to $FF) or decimal (0-255). However, the number is always stored in decimal.
• Mask - The number in this field is used to isolate the bits inside of the byte specified by the Offset field. This value is AND'ed with the value present in the byte and the result is examined. If you enter $FF, EtherHelp examines all of the bits in the byte, while a mask of 80 causes EtherHelp to examine only the most significant bit.
• Value - The number in this field is the "constant" that EtherHelp compares to the value it obtains by applying the Mask to the Offset byte. If the value specified here matches the value in the specified byte (or bits) in a packet, the test passes.
Creating An Example Offset Filter
This example creates an offset filter to capture AppleTalk packets of a specific datagram length. To create the filter, you must first know that the "datagram length" field in AppleTalk packets is a 10-bit field that begins in the 22nd byte of a packet with the 2 least significant bits and continues as the eight bits in the following byte. So, this filter will need to include tests for both the 22nd and 23rd byte of each packet. This type of information can be found in "Inside AppleTalk, Second Edition".
Say that you want to capture all AppleTalk packets with a datagram length of 420 (0x1A4). The total value to test for is 420 (0x1A4). First, make sure that existing filters will not prevent these packets from being captured; in fact, you might want to limit capture to just AppleTalk packets. Then, follow these steps:
1. Select "Filtering..." from the Capture menu.
2. Select "Add..." from the Filters menu.
3. Assign a name to the filter, e.g., "DDP Long".
4. Click the Offset Filters button to open the Offset Filter window.
5. Click the first check box to enable this test, and then type a name in the Name field to remind you of the function of this test; e.g.: "DDP len-hi".
6. Specify the byte you want to examine, in this case byte 22, by typing a hex value in the Offset field: "0x15". Hex 15 is decimal 21, which represents the 22nd byte of the packet.
7. Specify the bits within this byte, in this case the 2 least significant bits, by typing a hex value in the Mask field: "0x3".
8. Specify the constant value "1" in the Value field: 0x1. The total value to test for is 420 (0x1A4), so the value for byte 22 should be 1.
9. Click the second check box to enable this test, and then type a name in the Name field to remind you of the function of this test, e.g.: "DDP len-low".
10. Specify the byte you want to examine, in this case byte 23, by typing a hex value in the Offset field: "0x16". Hex 16 is decimal 22, which represents the 23rd byte of the packet.
11. Specify the bits within this byte, in this case all eight bits, by typing a hex value in the Mask field: "0xff".
12. Specify the constant value "A4" in the Value field: "Oxa4". The total value to test for is 420 (Ox1A4), so the value for byte 23 should be A4.
13. Click OK.
14. In the Filter Settings window, click the Offset Filter box to enable this filter.
15. Type a name in the Filter: edit field at the top of the window.
16. Click OK to exit, or click "Add More..." if you want to create new filters.
Error filters
Error filtering allows you to capture or ignore packets that contain errors.
When to Filter Error Packets
Sometimes Ethernet errors are normal. Because of the way Ethernet does signalling on the wires, there is a certain amount of probability that 2 network devices will occasionally have a collision as they both try to communciate at the same time. The frequency of collisions is dependent on the amount of traffic on the network or, more specifically, the percentage of idle vs. non-idle time on the wires. Sometimes Ethernet hardware will detect a collision during the transmission sequence, back-off a random amount of time, amd then try again. Also, most protocols are designed with redundancy and retransmissions as part of their normal operation. Because of these factors, errors do not necessarily mean lost data, but probably do mean slower network speeds. Normal collisons may show up as any of 4 error types, though usually not as oversize packets.
If you are using EtherHelp on a high-traffic network, or on a Mac that is significantly slower than other devices on the net, you can decide not to capture packets affected by "normal" error conditions by using error packet filtering. To create an error packet filter, simply check the "Error Filter" box in the "Filter Settings" window, and also check the specific error type box to enable and error packet filter.
Triggering
You may wish to keep EtherHelp idle or in a holding pattern (continuously capturing) until a specific event occurs on your network. These events can be one or more of the following:
• an address or protocol type appears in a packet on the network
• a user-defined value in some bits or bytes appears in a packet on the network
• an error packet is received
• the Macintosh system clock reaches a user-defined time
When one of these events occur, EtherHelp can begin capturing packets. The automatic start of data capture based on network events is called Triggering.
Trigger Start
To configure EtherHelp to recognize a trigger event, you must specify the trigger parameters and then use a check box to indicate if the trigger is enabled or disabled. Each enabled trigger event is independent of the others that have been enabled, i. e., capture is started if any of the enabled trigger events occur.
• The “Time” trigger event causes packet capture to start at a specified time.
• The “Filter” trigger causes capture to start when a checked filter is passed.
• The “Start Capture” check box is used to specify that capture of all packets, according to the filters, should begin when any of the trigger event conditions is met.
• The “Notify” box is used to cause an audible alarm at the occurrence of the trigger event.
NOTE: If the “Start Capture” check box is not checked, but the “Notify” check box is checked, only packets which cause the trigger event will be captured.
When Start Triggering is enabled, a small diamond appears next to the "Start Trigger..." item in the Capture menu and the "Start Capture" button turns into a "Start Trigger" button. By clicking on this button, or by using the "Start Trigger" item in the Capture menu, EtherHelp begins reviewing but NOT capturing packets until the trigger criteria is met.
Once clicked, EtherHelp will begin monitoring packets on the network and will continue to do so until one of the packets matches an enabled trigger criteria. If the “Notify upon trigger event” check box is checked, and the “Start capture upon trigger event” check box is not checked, the packet causing the trigger will be captured, and EtherHelp will continue waiting for more trigger matches.
After triggering is activated, the button will be renamed to Abort Trigger. When the trigger event occurs, capture begins and the button reverts to its normal label of Stop Capture.
Saving and Restoring Settings
The settings file contains all the information required to set up filters and triggers. After you have set up your filters and triggers, Etherhelp will remember the settings each time it starts up. However, you can also save these settings to a separate file so that they can be selectively restored as required. In fact, you may have received an EtherHelp settings file from your vendor in order to streamline capture and subsequent diagnosis. A settings file is useful when different configurations of settings are repeatedly used for things like diagnostics and testing. To save and restore configuration settings, use the "Save Settings" and "Load Settings..." items from the File menu.
